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COMMUNICATION DEVICE AND PROGRAM 

[0001] This application claims priority under 35 U.S.C. §1 19 to Japanese 
Patent Application No. 2003-096088 filed March 31, 2003, the entire content of 
which is hereby incorporated by reference. 

TECHNICAL FIELD 

[0002] The present invention relates to a technology for determining 
authenticity of downloaded data. 

BACKGROUND ART 

[0003] Commonly, software is downloaded to communication devices through 
communication networks such as the Internet, and is used in those communication 
devices. However, such downloading and use of software raises a risk of data 
hacking attacks, which can result in unauthorized accesses to data. If unauthorized 
access is obtained, malicious software can be downloaded to the communication 
device. 

[0004] To counter this problem, a variety of technologies for determining 
authenticity of downloaded software have been developed. For example, a 
method has been proposed where prior to downloading software, a user is supplied 
with an Integrated Circuit card (referred to as 'IC card hereinafter) by a provider 
of the software, the IC card containing a hash value, which enables a user to 
authenticate the software. (For example, refer to Japanese patent laid-open No. 
1 1-205767). By this method, when a user instructs a communication device to 
download software after the IC card has been loaded in the communication device, 
the communication device downloads the software and calculates a hash value of 
the software using a hash function. Then, the communication device compares the 
calculated hash value and the hash value stored in the IC card so as to determine 
whether the values match, and therefore whether the received software is 
authorized for download to the device. 

[0005] Relevant to the method described above is the popularity of mobile 
stations which are able to download Java (registered trademark) application 
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software (referred to as 'Java-AP software' hereinafter), and to execute an 
application program contained in the downloaded Java-AP software (the 
application program will be referred to as 'Java-APP' hereinafter). 
[0006] When Java-AP software is downloaded to such a mobile station, first an 
Application Descriptor File (referred to as an 'ADF' hereinafter) is downloaded 
from a server device contained in the World Wide Web (referred to as ' WWW 5 
hereinafter) to the mobile station, and then a Java Archive file (referred to as a 
6 JAR file' hereinafter), which contains a Java-APP, is downloaded to the mobile 
station. 

[0007] It is to be noted that in this specification the term * Java-AP software' 
refers to a combination of an ADF and a JAR file. One problem affecting files 
comprising Java-AP software for download to a mobile station, is that they may be 
subject to a malicious attack. Accordingly, it is necessary to confirm, in advance, 
authenticity of software to be downloaded. 

[0008] An ADF is a file containing information data about a corresponding 
JAR file. Such information includes, for example, a date when the JAR file was 
updated. Thus, to maintain parity, when the JAR file is updated the corresponding 
ADF must also be updated. In this way, by confirming proper correspondence of 
relevant JAR file and ADF, it is possible to confirm authenticity of Java-AP 
software. 

[0009] One method that has been proposed with this aim in view is as follows. 
First, an ADF and a JAR file having a valid correspondence are integrated in a 
single file. Then a hash value of the integrated file is calculated. The hash value 
is used to determine whether a downloaded ADF and a JAR file have a valid 
correspondence. A method similar to this is proposed in the above-mentioned 
patent document (Japanese patent laid-open No. 1 1-205767). 
[0010] A Java-APP contained in a JAR file will commonly be subject to a 
variety of modifications which are implemented by a provider to fix bugs in or 
upgrade the program. However, each time the Java-APP is modified, the hash 
value of the Java-AP software will change. As a result, it becomes necessary for 
the provider of the Java-APP, namely a Contents Provider (referred to as 'CP' 



hereinafter), to distribute IC cards containing a new hash value to mobile stations 
in which the Java-APP has been modified or upgraded. Provision and distribution 
of such cards upon each modification and upgrade of a program would, however, 
obviously result in unacceptable costs and logistical problems, and is therefore 
unrealistic. 

[0011] In view of this situation, the present invention is aimed at providing a 
means for confirming authenticity and valid correspondence of multiple files. 

DISCLOSURE OF THE INVENTION 

[0012] To solve the problem described above, the present invention provides a 
communication device comprising: a receiving means for receiving (a) a first file 
which contains data indicating a certain value which is calculated on the basis of 
data of a certain type contained in another file, and (b) a second file which 
contains data of the certain type; a calculating means for calculating a value which 
is obtained for assigning the data of the certain type contained in the second file to 
a one-way function; a comparing means for comparing the value which is 
calculated by the calculating means and the certain value indicated by the data 
contained in the first file; and a determining means for determining validity of 
correspondence of the first file and the second file according to a result of the 
comparison made by the comparing means. 

[0013] The present invention further provides a program for instructing a 
computer to execute: a receiving step for receiving, (a) a first file which contains 
data indicating a certain value which is calculated on the basis of data of a certain 
type contained in another file, and (b) a second file which contains data of the 
certain type; a calculating step for calculating a value which is obtained for 
assigning the data of the certain type contained in the second file to a one-way 
function; a comparing step for comparing the value which is calculated in the 
calculating step and the certain value indicated by the data contained in the first 
file; and a determining step for determining validity of correspondence of the first 
file and the second file according to a result of the comparison made in the 
comparing step. 



[0014] According to the present invention, data of a certain type contained in 
the second file received by the receiving means is assigned to a one-way function, 
and a value obtained from the one-way function is compared to a value indicated 
by data contained in the first file, which is also received by the receiving means. 
Then, authenticity of a combination of the first file and the second file is 
determined on the basis of a result of the comparison. Thus, according to the 
present invention, validity of correspondence of plural files which relate to one 
another, such as a series of files comprising software, can be confirmed. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0015] Fig. 1 is a block diagram illustrating configurations of a delivery system 
according to an embodiment of the present invention. 

[0016] Fig. 2 is a conceptual drawing illustrating a typical data structure of an 
ADF used in the system. 

[0017] Fig. 3 is a conceptual drawing illustrating a data structure of a SDF 
stored in a trusted server device of the system. 

[0018] Fig. 4 is a block diagram illustrating configurations of a mobile station 
contained in the system. 

[0019] Fig. 5 is a conceptual drawing illustrating a functional structure of the 
mobile station. 

[0020] Fig. 6 is a sequence chart illustrating data flows in the embodiment of 
the present invention. 

[0021] Fig. 7 is a flowchart illustrating processes for determining authenticity 
of downloaded files executed in the mobile station. 

PREFERRED EMBODIMENTS FOR CARRYING OUT THE 
INVENTION 

[0022] In the following description, a delivery system, which is realized by 
implementing an embodiment of the present invention, will be explained with 
reference to the drawings. In the drawings, like elements are denoted by like 
reference numerals. 



[0023] According to the delivery system, a user of a mobile station is able to 
(safely) instruct the mobile station to download desired Java-AP software, install a 
Java-APP contained in the downloaded Java-AP software, and run the Java-APP. 
[0024] Java-AP software is downloaded to a mobile station in the delivery 
system as follows. First, the mobile station displays an introductory explanation 
of the Java-AP software for the user. When the user instructs the mobile station to 
download the Java-AP software, the mobile station first receives an ADF of the 
Java-AP software. Then the mobile station receives a file called a Security 
Description File (referred to as a 'SDF' hereinafter) corresponding to the Java-AP 
software. Lastly, the mobile station receives a JAR file of the Java-AP software. 
SDF files contain data indicating behavior restrictions applicable to corresponding 
Java-APPs existing in a mobile station. Thus, when a mobile station runs a Java- 
APP, the mobile station controls, on the basis of conditions indicated in a 
corresponding SDF, behavior of an application provided by the Java-APP. 
[0025] In this specification, the term 'application' means a group of functions 
which are provided by a CPU when the CPU runs a program. In the following 
explanation, to describe a situation where a CPU runs a Java-APP to provide a 
group of functions, namely a Java-AP, the expression 'a Java-AP is realized' will* 
be used. An application which is realized by a Java-APP is called a 'Java-AP' 
hereinafter. 

[0026] A SDF is prepared by the above-mentioned carrier upon completion of 
a contract made between the carrier and a CP who provides the Java-AP software. 
In the delivery system in the present embodiment, some Java-APPs have 
corresponding SDFs, but other Java-APPs do not have corresponding SDFs. 
Behavior of a Java-AP realized by a Java-APP which has a corresponding SDF is 
restricted on the basis of the SDF. Such Java-AP and Java-APP are called 'trusted 
Java-AP' and 'trusted Java-APP' in this specification, since reliability is 
guaranteed by the carrier according to a contract made between the carrier and a 
CP which provides the Java-APP. 

[0027] In the following explanation of the present embodiment, 'Java-AP 
software' can mean a combination of an ADF, a SDF and a JAR file when the 



Java-APP contained in the JAR file is a trusted Java-APP, or can mean a 
combination of an ADF and a JAR file when the Java-APP contained in the JAR 
file is not a trusted Java-APP. In this specification, a Java-APP which is not a 
trusted Java-APP is called an 'untrusted Java-APP', and an application which is 
realized by an untrusted Java-APP is called an * untrusted Java-AP\ In the same 
way, in this specification, Java-AP software which contains a trusted Java-APP is 
called 'trusted Java-AP software 5 , and a Java-AP which contains an untrusted 
Java-APP is called 'untrusted Java-AP software'. 
[0028] (1: Configuration) 

As shown in Fig. 1, the delivery system comprises: CP server device 12 
connected to Internet 1 1 ; mobile packet communication network 15 through which 
the carrier provides mobile packet communication services to mobile stations; 
mobile station 16 which exchanges data packets with other communication 
devices through mobile packet communication network 15; gateway server device 
17 which interconnects Internet 1 1 and mobile packet communication network 15; 
and trusted server device 18 which is connected to gateway server device 17. 
Although in practice, the delivery system may comprise plural mobile stations, for 
the sake of simplicity only one mobile station 1 6 is shown in Fig. 1 . Accordingly, 
only one CP server device 12 is shown in Fig. 1. 

[0029] In the following, details of each component of the delivery system are 
explained. 

[0030] (1-1: CP server device) 

CP server device 12 has hardware components and features of a general 
WWW server device. CP server device 12 comprises hard disk device 12 A. CP 
server device 12 is able to establish a connection following Transmission Control 
Protocol (referred to as 'TCP' hereinafter), between CP server device 12 and a 
communication device. When CP server device 12 receives a request message 
following a GET method of Hypertext Transfer Protocol (referred to as 'HTTP' 
hereinafter) using the TCP connection, CP server device 12 reads out a file 
identified by a Uniform Resource Locator (referred to as a 'URL' hereinafter) 
which is assigned to the GET method from hard disk device 12 A, transmits a 
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response message of HTTP containing the file to the communication device, and 
disconnect the TCP connection. 

[0031] Hard disk device 12A stores JAR files containing programs written in 
Java programming language, and ADFs containing data indicating information on 
their corresponding JAR files. 

[0032] ADFs stored in CP server device 12 are categorized into ADFs which 
correspond to trusted Java-APPs, and ADFs which correspond to untrusted Java- 
APPs. Both types of ADFs contain data which are contained in a normal ADF in 
the prior art, such as data indicating a name of Java-AP software, a JAR storage 
URL which is data indicating a storage location of a JAR file in WWW, data 
indicating a size of the JAR file, data indicating a date of the last update of the 
JAR file, and so on. Each of the ADFs which correspond to trusted Java-AP 
software contains, as shown in Fig. 2: trusted APID which is an identifier 
assigned to each trusted Java-AP software; data indicating a trusted server domain 
which specifies a storage location of a corresponding SDF in WWW, certificate 
data which is provided from a Certificate Authority (referred to as a 'CA' 
hereinafter) to a CP who operates CP server device 12; and a JAR hash value 
which indicates a hash value of a corresponding JAR file, in addition to the above- 
mentioned data. 

[0033] A hash value is a value of a fixed length which is obtained as an output 
of a hash function when arbitrary data are input to the hash function. A hash 
function is one example of a one-way function. A 'one-way function' is a 
function in a form of c y = f(x)' where y is calculated quickly when x is given but 
where it is practically impossible to calculate x when y is given, since the function 
has no inverse function, and it would therefore take an inordinate amount of time 
to calculate x. 

[0034] CP server device 12 has a function for generating and updating files 
containing the above-mentioned data in accordance with instructions of the CP. 
Hard disk device 12A also stores certificate data, which is issued by a CA, and 
certificates that the CP is authenticated by the CA. CP server device 12 further 
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stores a program for calculating hash values of JAR files and certificate data 
following Secure Hash Algorithm 1 (referred to as 'SHA-1 ' hereinafter). 
[0035] (1-2: Gateway server device) 

Gateway server device 17 is managed by the above-mentioned carrier, and 
has hardware components and features of a general WWW server device, which 
device interconnects communication networks. Gateway server device 17 relays 
data between mobile packet communication network 1 5 and Internet 11. 
[0036] (1-3: Trusted server device) 

Trusted server device 1 8 is managed by the above-mentioned carrier, and 
has hardware components and features of a general WWW server device. Trusted 
server device 18 comprises hard disk device 18A, and after establishing a TCP 
connection with a communication device, when trusted server device 1 8 receives a 
request message following a GET method of HTTP using the TCP connection, 
trusted server device 18 reads out a file identified by a URL which is assigned to 
the GET method from hard disk device 1 8 A, transmits a response message of 
HTTP containing the file to the communication device, and disconnects the TCP 
connection. 

[0037] Hard disk device 1 8 A stores SDFs each of which corresponds to each 
of trusted Java-APPs. 

[0038] A SDF is a file made by the carrier for a trusted Java-APP. As shown 
in Fig. 3, a SDF contains: a JAR storage URL which indicates a URL of a storage 
location of a JAR file containing the trusted Java-AP; an ADF certificate data flag 
which indicates whether a corresponding ADF contains certificate data; a 
certificate hash value which indicates a hash value calculated in accordance with 
the certificate data contained in the ADF; and permission data which indicates 
Application Program Interfaces (referred to as 4 APIs' hereinafter) or URLs which 
a trusted Java-AP realized by the trusted Java-APP is permitted to use or access. 
[0039] Permission data includes 'permission data for accessing personal data' 
which indicates whether it is permitted for the trusted Java-AP to use APIs for 
accessing telephone directory data, unread email data and outgoing/incoming 
email history data, 'permission data for changing setting' which indicates whether 



it is permitted for the trusted Java-AP to use APIs for changing settings of a 
melody or an image for notifying email arrivals/transmissions, and an image for a 
non-prompting screen, and 'permission data for URLs' which indicates URLs 
which the Java-AP is permitted to access. 
[0040] (1-4: Mobile station) 

As shown in Fig. 4, Mobile station 16 comprises: an Operating System 
(OS) program; a Java-AP environment program for establishing an environment 
for making Java-APs operable; ROM 16A for storing various kinds of programs 
such as native application programs; CPU 16B for running programs stored in 
ROM 16A; display unit 16C; nonvolatile memory 16D; RAM 16E; 
communicating unit 16F; and operating unit 16G. These components of mobile 
station 16 are connected to one another by way of a data bus. 
[0041] Display unit 16C comprises, for example, a liquid crystal display panel 
and a panel driver circuit, and displays images constructed from data which are 
provided by CPU 16B. 

[0042] Nonvolatile memory 16D is, for example, a Static Random Access 
Memory (SRAM) or an Electrically Erasable and Programmable Read Only 
Memory (EEPROM). Java-AP software which is downloaded from server devices 
contained in the WWW is stored in nonvolatile memory 16D. Nonvolatile 
memory 16D also stores a program for calculating hash values following SHA-1. 
[0043] Communicating unit 16F comprises an antenna and a wireless 
communication unit; wirelessly communicates data packets with mobile packet 
communication network 15, and relays data packets between CPU 16B and mobile 
packet communication network 15. Communicating unit 16F comprises a 
CODEC, a microphone and a speaker for voice communication; and enables 
mobile station 16 to conduct voice communication through a mobile telephone 
network (not shown) which has a line switching system. 

[0044] Operating unit 16G comprises hardware such as keypad for a user to 
input operations; and provides CPU 16B with certain signals in accordance with 
operations carried out by the user. 
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[0045] (2. Operation) 

In the following description, example operations of the above-mentioned 
delivery system are explained. 

[0046] When a power supply (not shown) of mobile station 16 is turned on, 
CPU 16B reads the OS program stored in ROM 16A and run the OS program 
using RAM 1 6E as a work area. Following instructions of the OS program, CPU 
16B is capable of providing several basic functions such as controlling User 
Interface (UI). Fig. 5 shows a structure of an OS which is realized in mobile 
station 16 by the OS program. The OS specifies instructions provided by the user 
on the basis of signals received from operating unit 16G in accordance with 
operations of the user, and carries out certain processes in accordance with the 
instructions. 

[0047] For example, when the user requests download of Java-AP software, a 
Web browser in the OS transfers the request to a Java Application Manager 
(referred to as a 6 JAM' hereinafter). 

[0048] When the user requests running of a JAM program, which is a native 
application program of mobile station 16, the OS starts the JAM program and 
realizes a JAM in mobile station 16. The JAM displays a list of Java-APPs 
installed to mobile station 16, and when the user selects one of the listed Java- 
APPs, the JAM starts the selected Java-APP. More concretely, when mobile 
station 16 receives from the user an instruction to start a certain Java-APP, the 
Java-AP environment program is started by CPU 16B, and a Java-AP environment 
is established in mobile station 16. Then, the Java-APP is started by CPU 16B 
using the Java-AP environment, and functions of a Java-AP are provided. A Java- 
AP environment contains, for example, K Virtual Machine (KVM) which is a 
lightweight Java virtual machine tuned to a mobile station such as mobile station 
16, and APIs which provide several functions for Java-APs. APIs which are 
prepared for Java-APs are categorized into trusted APIs which only trusted Java- 
APs are permitted to use following permission data contained in SDFs, and 
untrusted Java- APIs which all Java-APs are permitted to use. 
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[0049] Explanations of operations for establishing and disconnecting TCP 
connections are omitted in this specification, since the operations follow a well- 
known method of HTTP. In the following explanation, operations which are 
executed by CPU 16B following instructions of the above-mentioned programs, 
such as the OS program, a Web browser program, a JAM program, a Java-APP 
and a native application program, are described as 'operations carried out by 
mobile station 16' to simplify the description. 
[0050] (2-1: Preparation of trusted Java- AP software) 

In the following, operations for CP server device 12, which is managed by 
a CP, to prepare a trusted Java-APP are explained with reference to Fig. 6. 
[0051] The carrier provides to the CP in advance a program for calculating 
hash values of JAR files and certificate data following SHA-1. The program is , 
referred to as a 'tool' hereinafter. Hard disk device 12A of CP server device 12 
stores the tool as well as the certificate data received from the CA. 
[0052] The CP prepares a Java-APP for realizing a Java-AP which is capable 
of changing melodies for notifying email arrivals in accordance with telephone 
numbers of senders of emails. The Java-APP is named 'Melody by Telno Appli'. 
The CP instructs CP server device 12 to generate a JAR file containing a 'Melody 
by Telno Appli', and to store the JAR file in a storage location identified by a 
storage URL of 'http://www.bxo .jp/melody .jar'. On the other hand, the CP inputs 
data to be contained in an ADF, such as data indicating the name of the Java-APP 
'Melody by Telno Appli' and the JAR storage URL, to CP server device 12. 
Then, the CP instructs CP server device 12 to run the tool. 
[0053] Following the instruction of the CP, the CPU of CP server device 12 
reads the tool stored in hard disk device 12 A, and following instructions of the 
tool, calculates a hash value of the JAR file (referred to as a 'JAR hash value' 
hereinafter) and a hash value of the certificate data (referred to as a 'certificate 
hash value' hereinafter). Then, the CPU of CP server device 12 generates an ADF 
which contains data indicating the JAR hash value, the certificate data, the data 
indicating the name of Java-APP 'Melody by Telno Appli', and the data indicating 
the JAR storage URL 'http://www.b.co.jp/melody.jar'. 
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[0054] Then, CP server device 12 transmits, to trusted server device 18, the 
ADF and the JAR file along with data indicating the certificate hash value (step 
SI). 

[0055] When the carrier, which manages trusted server device 18, receives the 
above-mentioned files and data from CP server device 12, the carrier determines 
whether the CP is authorized. 

[0056] More concretely, the carrier checks whether the certificate data 
contained in the ADF is issued by a CA which the carrier relies on, or whether the 
certificate data is issued by plural CAs with a valid certificate chain and the plural 
CAs are managed by a CA of a higher level which the carrier rely on. 
[0057] After completing the authenticity check, the carrier determines 
authenticity of the Java-APP provided by the CP. More concretely, the carrier 
inspects descriptions of the Java-APP contained in the JAR file to check whether 
the Java-AP realized by the Java-APP does not destroy personal data stored in 
mobile station 16, not leak the personal data to an external device, and so on. 
[0058] After the inspection of the program, the carrier determines APIs which 
the Java-AP is permitted to use and URLs which the Java-AP is permitted to 
access, in accordance with a result of the inspection. The carrier then inputs data 
indicating the APIs and URLs to trusted server device 18. 

[0059] In response to the input, the CPU of trusted server device 1 8 generates a 
SDF which corresponds to the ADF and the JAR file received from CP server 
device 12. The SDF generated by the CPU contains data indicating the JAR 
storage URL 'http://www.bxo.jp/melody .jar' contained in the ADF, an ADF 
certificate data flag 'YES', data indicating the certificate hash value received from 
CP server device 12, and permission data indicating the APIs and the URLs input 
by the carrier. 

[0060] After generating the ADF, the CPU of trusted server device 1 8 adds 
data indicating a trusted APID '0001 which identifies the trusted Java-APP, and 
data indicating a trusted server domain 6 http://www.a.co.jp/melody.sdf , which 
identifies a storage location of the SDF in trusted server device 18. Then, the CPU 
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transmits the ADF containing the above-mentioned data to CP server device 12 
(step S2). 

[0061] The CPU of CP server device 12 receives the ADF and stores the ADF 
in hard disk device 12 A. After the storage of the ADF in CP server device 12, the 
JAR file containing the Java-APP becomes ready to be downloaded to mobile 
station 16. 

[0062] (2-2: Download of Java-AP software to mobile station 16) 

In the following, operations which are executed in the delivery system 
when the user instructs mobile station 16 to download Java-AP software, will be 
explained with reference to Fig. 6. 

[0063] In the following explanation, it is supposed that the ADF and the JAR 
file of the Java-AP software to be downloaded are not modified after the Java-AP 
software is prepared, as explained in section 2-1 . 

[0064] The user instructs mobile station 16 to download the trusted Java-APP 
'Melody by Telno Appli' from CP server device 12 to mobile station 16 by using 
operating unit 16G. 

[0065] When CPU 16B receives the instruction made by the user for 
downloading the trusted Java-AP software through the Web browser, CPU 1 6B 
carries out a series of processes for downloading the trusted Java-APP to mobile 
station 16 as follows. 

[0066] First, CPU 16B receives the ADF corresponding to the Java-APP from 
CP server device 12. More concretely, CPU 16B establishes a TCP connection 
with CP server device 12, generates a request message for transmitting the ADF, 
and transmits the request message to CP server device 12 (step S3). CPU 16B 
receives a response message containing the ADF in response to the request 
message (step S4), and disconnects the TCP connection. After receiving the 
response message, CPU 16B stores the ADF contained in the response message in 
nonvolatile memory 16D. 

[0067] Then, CPU 16B determines whether the Java-APP to be downloaded is 
a trusted Java-APP. More concretely, CPU 16B checks whether the ADF contains 
data indicating a trusted APID, and when the ADF contains the data, CPU 16B 
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determines that the Java-APP is a trusted Java-APP since the data indicates that 
there is a SDF corresponding to the Java-APP. On the other hand, when the ADF 
does not contain the data, CPU 16B determines that the Java-APP is an untrusted 
Java-APP. 

[0068] In a case that the Java-APP to be downloaded is an untrusted Java-APP, 
mobile station 16 downloads the JAR file from a storage location, which is 
identified by the data indicating the JAR storage URL contained in the ADF, 
following the same procedures as carried out in a normal delivery system in the 
prior art. 

[0069] In this example case, since the ADF contains data indicating the trusted 
APID '0001 \ CPU 16B determines that the Java-APP to be downloaded is a 
trusted Java-APP. Accordingly, CPU 16B receives the SDF which corresponds to 
the Java-APP from a storage location identified by the data indicating the trusted 
server domain c http://www.a.co.jp/melody.sdf. More concretely, CPU 16B 
establishes a TCP connection with trusted server device 18, generates a request 
message for transmitting the SDF, which is identified by the trusted server domain 
c http://www.a.co.jp/melody.sdf indicated by the data contained in the ADF, and 
transmits the request message using the TCP connection (step S5). CPU 16B 
receives a response message containing the SDF in response to the request 
message (step S6), and disconnects the TCP connection. 

[0070] In the following, operations for determining authenticity of the trusted 
Java-AP software after downloading the trusted Java-AP software are explained 
with reference to Fig. 7. 

[0071] CPU 16B determines whether the ADF contains certificate data (step 
SI 01). More concretely, CPU 16B checks whether the ADF contains ADF 
certificate data flag indicating 'YES'. When CPU 16B determines that the ADF 
does not contain certificate data (step SI 01; No), CPU 16B skips the processes for 
inspecting certificate data, and moves to processes for downloading the JAR file 
(step SI 04). 

[0072] In this example case, since the ADF contains the ADF certificate flag 
data indicating 'YES', CPU 16B determines that the ADF contains certificate data 
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(step S101; Yes), and calculates* a hash value of the certificate data contained in 
the ADF (stepS102). 

[0073] After calculating the hash value, CPU 16B compares the calculated 
hash value and the hash value contained in the SDF to determine whether they are 
identical to each other (step SI 03). If the hash values are not identical to each 
other (step SI 03; No), a possibility exists that the certificate data contained in the 
ADF has been modified by somebody after the carrier prepared the SDF. 
Therefore, CPU 16B notifies a download failure to the user, deletes the ADF, 
restores software configurations in mobile station 16 in a state before the ADF was 
downloaded (step SI 07), and terminates the processes for downloading the Java- 
AP software. 

[0074] In this example case, the hash values are determined to be identical to 
each other (step SI 03; Yes), and CPU 16B downloads the JAR file to mobile 
station 16 (step SI 04). More concretely, CPU 16B establishes a TCP connection 
with CP server device 1 2 using the JAR storage URL 

'http://www.b. co.jp/melody .jar', which is contained in the ADF, and indicates a 
storage location in CP server device 12 where the JAR file is stored, generates a 
request message for transmitting the JAR file, and transmits the request message* 
to CP server device 12 (step S7 in Fig. 6). CPU 16B receives a response message 
containing the JAR file from CP server device 12 in response to the request 
message (step S8 in Fig. 6), and disconnects the TCP connection. 
[0075] After receiving the response message, CPU16B calculates a hash value 
of the JAR file contained in the response message (step SI 05). CPU 16B 
compares the calculated hash value and the JAR hash value contained in the ADF 
to determine whether they are identical to each other (step SI 06). When the hash 
values are not identical to each other (step SI 06; No), a possibility exists that the 
JAR file has been falsified or modified after the JAR file was prepared. Therefore, 
CPU 16B notifies a download failure to the user, deletes the ADF and the JAR 
file, restores software configurations in mobile station 16 to a state before the ADF 
was downloaded (step SI 08), and terminates the processes for downloading the 
Java-AP software. 
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[0076] In this example case, the hash values are identical to each other (step 
SI 06; Yes). Accordingly, CPU 16B notifies to the user that the Java-AP software 
was downloaded successfully, stores the received JAR file and the received SDF 
in nonvolatile memory 16D (step SI 09), and completes the processes for 
downloading the Java-AP software. 

[0077J After completing the downloading processes for the trusted Java-AP 
software, CPU 1 6B monitors behavior of a trusted Java-AP realized by the trusted 
Java-APP contained in the JAR file, and permits or restricts use by the Java-AP of 
APIs for accessing personal data such as the telephone directory data and for 
changing settings of mobile station 16, and access to URLs, in accordance with the 
permission data for accessing personal data, the permission data for changing 
setting, and the permission data for URLs respectively, which are contained in the 
SDF. 

[0078] As explained above, according to the present embodiment, it is possible 
to determine whether certificate data which is contained in an ADF has been 
modified or after the carrier has determined authenticity of the certificate data, by 
verifying that a hash value, which is calculated using the certificate data contained 
in the ADF, and a hash value calculated in advance using the certificate data and 
contained in a corresponding SDF, are identical to each other. In short, according 
to the present embodiment, authenticity of a combination of a SDF and an ADF is 
determined. 

[0079] When the certificate data in the ADF is overwritten with the same 
certificate data as contained in the SDF, hash values of both of the certificate data 
become identical, and the combination of the SDF and the ADF is determined as 
authenticated, even when the ADF is modified after the SDF was prepared. 
Accordingly, if the CP needs to modify the ADF to modify the JAR file for the 
purpose of, for example, fixing bugs in the JAR file, after the carrier determines 
authenticity of the certificate data, the CP is able to maintain authenticity of the 
combination between the SDF and the ADF on the basis of the same certificate 
data in the modified ADF as is used in the original ADF. Therefore, the carrier 
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does not have to repeat operations for determining authenticity of the certificate 
data when the ADF is modified by the CP. 

[0080] Moreover, according to the present embodiment, it is possible to 
determine whether a JAR file which is downloaded from a CP has been modified 
or falsified after the carrier determines authenticity of the JAR file, by verifying 
that a hash value which is calculated using the downloaded JAR file and a hash 
value which was calculated in advance using the JAR file and contained in a 
corresponding ADF are identical to each other. In short, according to the present 
embodiment, authenticity of a combination of a JAR file and an ADF is 
determined. Accordingly, use of a falsified JAR file in mobile station 16 can be 
prevented. 

[0081] Moreover, according to the present embodiment, there is no need to 
distribute to each mobile station in advance a recording medium such as an IC 
card which contains a hash value. 

[0082] Accordingly, in the delivery system according to the present 
embodiment, authenticity of combinations of ADFs, SDFs and JAR files can be 
readily determined. 

[0083] Since processes for calculating a hash value require far less computing 
resources than those for calculating a public key used in conventional 
authentication systems, the present embodiment can be adopted for use with a 
device whose computing resources are limited, such as a mobile station. 
[0084] (3: Modification) 

The present invention is not limited to the embodiment described above, 
and may be modified within the technical scope of the present invention. 
Following are examples of such modifications. 

[0085] (1) In the embodiment above, a SDF contains a hash value of 
certificate data, which is contained in an ADF which corresponds to the SDF, and 
mobile station 16 determines authenticity of a combination of the SDF and the 
ADF by comparing a hash value calculated by use of the certificate data contained 
in the ADF, and the hash value contained in the SDF. A hash value used in the 
delivery system is not limited to a hash value of certificate data, and a hash value 
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of another type of data contained in an ADF, or a hash value of the whole ADF 
can also be used for the same purpose. 

[0086] Moreover, in the embodiment above, an ADF contains a hash value of a 
corresponding JAR file, and mobile station 16 determines authenticity of a 
combination of the ADF and the JAR file by comparing a hash value calculated by 
use of the JAR file and the hash value contained in the ADF. A hash value used in 
the delivery system is not limited to a hash value of the whole of JAR file, and a 
hash value of a part of the JAR file can also be used for the same purpose. 
[0087] (2) In the embodiment above, hash functions using SHA-1 are used 
for calculating hash values for determining authenticity of combinations of files. 
However, other sorts of hash functions can also be used in the delivery system. 
For example, hash functions using Message Digest 5 (MD5) are also adopted to 
the delivery system according to the present invention. Moreover, all other sorts 
of one-way functions can be used in the delivery system, instead of the hash 
functions. 

[0088] (3) In the embodiment above, programs for determining authenticity 
of files are stored in a ROM of a mobile station. The programs may be stored any 
other sorts of storage devices such as an EEPROM of a mobile station. When the 
programs are stored in a re-writable storage device such as an EEPROM, the 
programs can be downloaded to the mobile station from an external device 
through the mobile communication network, and stored in the re- writable storage 
device. When the mobile station has an interface for communicating with an 
external storage device, the programs can be provided to the mobile station by 
connecting to the mobile station an external storage device such as a memory card 
containing the programs. In this case, the mobile station may read out the program 
directly from the external storage device and execute them. 
[0089] (4) In the above-explained embodiment, an ADF contains data 
indicating a trusted server domain, and a SDF, which corresponds to a trusted 
Java-APP to be downloaded to a mobile station, is identified on the basis of the 
data. A SDF may be identified in other ways. For example, mobile station 16 
may obtain data indicating a URL for identifying trusted server device 1 8 in 
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advance, and when mobile station 16 generates a request message for transmitting 
the SDF from trusted server device 18 to mobile station 16, mobile station 16 may 
add to the request message the URL identifying trusted server device 18 and data 
indicating a trusted APID for identifying the SDF corresponding to trusted Java- 
AP software to be downloaded. 



